A testbench, also referred to as a verification environment, refers to hardware description language (HDL) and/or hardware verification language (HVL) descriptions that specify and verify the behavior of a device under test (DUT), for example an IP (intellectual property) core or other circuit design. Generating a testbench involves describing the connections, events, and test vectors for different combinations of transactions involving the DUT. A testbench also refers to the code used to create a pre-determined input sequence to the DUT, as well as the code responsible for observing the response from the DUT.
Within a testbench, a watchdog timer is a standard mechanism for terminating a given test. If the watchdog timer times out, the test is terminated, as a timeout condition is indicative of an error condition or failure. The watchdog timer usually is loaded with a value that provides much more time than is needed for the test to complete, e.g., a value that is typically on the order of 10 times the time needed for the test to complete execution. Thus, if the test does not complete execution prior to the timeout condition, it is likely that a significant problem has occurred in testing the DUT. In other words, a timeout of the watchdog timer is an unwanted condition that is indicative of a significant problem with the DUT.
The time value that is loaded into the watchdog timer is a set value. While the value can be specified as a variable, it nonetheless is fixed. Utilizing a fixed value for the watchdog timer can introduce a significant amount of overhead into the DUT evaluation process. The watchdog timer, as noted, is loaded with a time value that far exceeds the time needed for even the most time consuming test to execute. When randomization is introduced into the testbench, the inefficiencies of watchdog timers can be further exacerbated.
For example, randomization may result in one test case completing execution in a small amount of time while another test case requires a much larger amount of time. Conventional systems load the watchdog timer with the same large, conservative value for both test cases. If an error occurs during the shorter duration test case, the testbench still waits until the watchdog timer expires before determining that an error has, in fact, occurred. The time between the occurrence of the error and the expiration of the watchdog timer is effectively wasted time.
Another layer of complexity is that testbenches often operate upon complex DUTs that incorporate several unrelated interfaces. In general, an interface refers to a collection of signals. A testbench interface tests the collection of signals, i.e., provides a mechanism for determining values for such signals at a given time during simulation. Interfaces can be said to be unrelated where, for example, each interface has an asynchronous clock and the interfaces are not synchronized except for the testbench having to access the interfaces, perhaps at a same specified time during simulation. With this in mind, it becomes necessary to execute some transactions in sequential fashion and others concurrently to adequately test a complex DUT.
It would be beneficial to implement a system that addresses the deficiencies described above.